Skip to main content
Version: 7.9

Resolve Actions Pro Concepts

Introduction​

The code concept of Resolve Actions Pro is the process-based work model. It is a complete set of steps integrated into a process. Actions Pro addresses three types of processes: manual, partially-automated, or fully-automated. The solution that you can create with Actions Pro include Documentation, Guided Processes - Decision Tree, and Runbook automation. A solution can be a combination of these three types.

IT Process Automation​

IT Process Automation (ITPA) is a wiki-based software designed to help capture and automate best practices for IT operations. The wiki-based automation platform promotes collaboration and process reuse without the overhead of traditional document management and business process management applications.

Actions Pro is an integrated automation system that leverages existing tools, scripts, and utilities to transform static procedures into collaborative, actionable processes that contain best practices. Some of the Actions Pro technical features are:

  • Collaborative wiki-based process and knowledge automation to capture best practices
  • Wiki Documents that support native HTML, Wiki syntax, template, and Groovy/Java scripting
  • Actionable Runbooks with embedded ActionTasks for executing automations on-demand or as an orchestrated process
  • Runbook Worksheets that contain actions and test results for multi-group problem diagnosis and resolution
  • Distributed agent and agent-less automation/integration to leverage existing tools, utilities, and scripts
  • Web user interface with role-based permissions and access controls

Runbooks and Sub-Runbooks​

The core concept of Actions Pro is the Runbook, also called a process. Traditionally, a Runbook is a written set of procedures for the routine operation of a computer system or network. With Actions Pro, a Runbook combines a wiki-based presentation with an automated process and manages all of the steps in an ActionTask or set of ActionTasks.

The term Runbook is used in Actions Pro to refer to both the automation model and the wiki document page that fronts the process. A sub-Runbook refers to a Runbook embedded within a larger, parent Runbook.
The results of an executed Runbook are stored in a Worksheet. There are several methods to execute a Runbook (See Automation Execution):

  • Direct execution from tasks, a task list, or right-click on an Automation Model object, or another Runbook.
  • User Interface (UI) action, such as a button to:
    • Schedule an action
    • Poll a database
    • Access or use a gateway such as Netcool
  • URL to:
    • Execute a task
    • Execute a Runbook
    • Command-line entry
    • Web Service call

Automation Models​

Runbook Automation (RBA) consists of ActionTasks that define how a specific process gets orchestrated in a series of steps. An Automation Model, resembling a flowchart diagram, is the graphic representation of the Runbook used to define and automate the process. It consists of (individual steps or tasks), embedded or sub-Runbooks, and business logic to be executed. The Automation Model may be completely autonomous and triggered by other systems, such as a ticketing system or fault management system, or interactively by users via wiki process documents.

All Automation Models include entry ("Start") and exit ("End") points, actions (ActionTasks), decision points (Preconditions), and conditional statements. (See Automation Development). They determine which ActionTasks to execute when, how data is passed between them, and how to respond to the results. An Automation

The model can contain tasks, sub-Runbook objects, events, containers, and components. The event feature pauses or stops Runbook execution to wait for some interaction before continuing (for example, a form that waits for user input or an email that was sent from a customer). An event can be another Runbook. An Automation Model can optionally contain a wiki document page as a visual interface presenting both static (procedural) or dynamic (ongoing result and status) information. There are two Automation model types in Actions Pro: Main and Abort. These models define the logical structure of tasks in a Runbook automation. The Main Model represents the steps executed normally by the Runbook. The Abort Model executes only if the Runbook following the Main Model is aborted or times out.                                     

Figure 2 – Basic Automation Model

For more about Automations refer to Automation Development.

ActionTasks​

ActionTasks define the commands used on a local system or RSRemote to carry out a test or action. An ActionTask encapsulates a single unit of behavior, and defines the action and the assessment or evaluation of the action in a Runbook. Each ActionTask involves several stages but is comprised of a command or script for execution and a script for the assessment or interpretation of the results. A typical "action" consists of:

  • Command-line executed in the system in which RSRemote is deployed.
  • Local script invoked by the RSRemote (for example, shell, Perl, VBScript, PowerShell, etc.).
  • Groovy script executed in the same JVM as the RSRemote.

If the execution of an ActionTask is successful, useful information gets saved for use downstream in a Runbook process. When multiple ActionTasks are connected together in a Runbook, they can be used to perform more complicated processes. ActionTasks typically use libraries to interact with external network devices, systems, and applications. The results of an executed ActionTask are stored in a Worksheet.

For more about ActionTasks, refer to ActionTask Development.

Version Control​

Maintaining and managing versions in Actions Pro is applied to Action tasks and Runbooks. It provides a visual indication to track the progress of the development work and history of the applied changes to the Runbook or Action task. Using the Automation Designer and the Action Task Builder development tools now gives the ability to view, rollback, purge, compare and update any existing version of that Runbook or Action Task. Searching for a specific version is made quick and easy using the Content Browser version history list.

You can use Version Control to: 

  • Facilitate concurrent development by reducing the risk for developers mixing over each other's work.
  • Encourage sharing of content between teams in order to speed up the development.
  • Ensure that a package's integrity is unchanged from environment to environment.
  • Reduce the deployment risk to override existing automations, so you can easily restore and maintain dependencies.
  • Select a version to run, or roll back to a previous version to run, to reduce the risk.
  • Select two versions and compare them in order to make an informed decision on which to be committed or reused in other environments.
  • Easily create a new version, manage existing versions, and permanently delete versions that are no longer relevant or used.

For detailed instructions on how to use Version Control refer to Version Control.

Wiki Documents and Procedures​

Wiki Document Pages are process documents that contain knowledge, instructions, or process information for a Runbook. They describe the procedure in detail and contain instructions and supporting information for the Runbook. The end-user, typically IT operators and service desk agents will follow and interact with the Runbook via wiki documents. The wiki allows the end-user to enter any necessary input parameters, start the execution, and view results in real-time.

Runbook procedures specify a series of actions or operations to achieve a given unit of work. A Runbook procedure consists of many elements, such as wiki documentation, forms, tables, results, and decision trees. Runbook processes can include management disciplines and interact with applications, databases, and hardware as well as many other element types. A process can include both automated as well as human interaction. The procedure can display outputs from automation as well as decisions. It also can display human interactive steps that get carried out by the end-user. 

For more about Wiki Documents, refer to Page Development.

The following figure shows a Runbook procedure with results.

Decision Trees​

Decision Trees allow knowledge documents (wiki pages) to be organized into a structured workflow. Similar to an automation model, a Decision Tree model resembles a flowchart, and defines navigation paths by connecting decision points (questions), answers, and documents. Users then navigate through the Decision Tree to perform self-service troubleshooting.

For more information about using a Decision Tree, see the Decision Tree Guide. For more about developing Decision Trees, refer to the Decision Tree Development catalog. For more about Decision Trees refer to Decision Tree Development.

Figure 5 – Decision Tree

Worksheets​

Runbook execution and assessed results are stored and viewed in a Worksheet, which collects returned information and provides a convenient reference for the state of one or more selected Runbook executions. Essentially, a Worksheet provides a history log of all actions carried out by Actions Pro. The Worksheet stores the results from the ActionTasks executed by the Automation Model or interactively executed by operators and service desk agents. A Worksheet can also reference records from external systems, such as incidents from a ticketing system or an alert from an event management system, which allows users to see automation results tied to a particular ticket or event.

Use the Worksheet Selector to access Worksheets. For more information, see Viewing Automation Execution Results and Automation Execution.

Request History​

The Request History menu group provides an easy way to view the history and status of Runbook and ActionTask execution requests. The menu group includes three main sections:

  • Process Requests: lists Runbook executions with Open, Completed, or Aborted status
  • Task Requests: lists ActionTask executions with Open, Completed, or Aborted status
  • Task Results: lists ActionTask and Runbook execution results, displayed similarly to the >Actions Pro Concepts - Worksheets.

See Automation Execution for more information.

Archive History​

Actions Pro archiving feature allows for automated archival of the Worksheet, Process Request, Task Request, and Task Result records. The Archive History menu group contains the following items:

  • Worksheet Archive
  • Process Request Archive
  • Task Request Archive
  • Results Archive

For further Archive History information, refer to Automation Execution or Automation Development.

Custom Forms and Tables​

Custom Forms are created using the Form Builder. The Form Builder allows developers to easily create drag and drop forms for interacting with Runbooks and the Actions Pro database. Custom Forms can be used for the following:

  • Create and edit a record form that maps a row in a table, with fields listing the data source as "DB"
  • Trigger a Runbook execution or execute a system script or send an event using an HTML form, with fields listing the data source as "INPUT"

Each form can have as many buttons as required and each can be configured to:

  • Update the table in the database
  • Execute a Runbook
  • Execute a script
  • Send an event

Custom Tables are developer-designed tables that can be used to store data in the Actions Pro database. Custom Tables get created based on company business rules. In addition to storing information in third-party applications, such as ticketing, billing, provisioning, and other systems, Actions Pro workflow and event-based state modeling enables process analysts to implement custom processes and applications that have previously been limited by traditional domain-specific applications.

Each table has two display screens:

  • List (Grid) View: displays all the table data records, and allows create and delete record options
  • Form (Edit) View: shows name, column headings, and different filtered views, with link to the associated custom form Admin rights are required in order to create Custom Tables.

For more about custom Forms, refer to Form Builder.

Gateways​

Gateways are integration points that provide Actions Pro with the ability to connect with external systems. Connectors provide API libraries that are invoked from within an ActionTask to talk to other systems over a temporary session. The session may be used for a number of ActionTasks; however, ActionTasks are typically disconnected once the usage completes.

Gateways, on the other hand, are persistent connections or connection pools that are established at start-up. Gateways provide bi-directional connectivity, as well as reducing the overhead of establishing a new connection on every Runbook. Certain Gateways also provide high availability/failover. For more about Gateways, refer to Gateways Administration guide.

The following table list the available gateways.

Integration NameIntegration TypeLatest Third Party Product Version Support
CA SpectrumGatewayCA Spectrum 10.x
ServiceNow GatewayGatewayServiceNow Madrid
Netcool GatewayGatewayIBM Netcool 8.x
EmailConnectConnectorN/A
EmailConnect2ConnectorN/A
EWS GatewayGatewayAll Versions supported
Email GatewayGatewayN/A
Exchange GatewayGatewayN/A
FTPConnectorN/A
InformixConnectorN/A
VTConnectorN/A
HtmlconnectConnectorN/A
PDFConnectorN/A
Salesforce GatewayGatewayN/A
HTTPGatewayN/A
SMTPGatewayN/A
SNMPGatewayN/A
SSHGatewayN/A
Database GatewayGatewayDB2, SQL, MySQL, MariaDB, PostGres, Oracle, Sybase
RemedyXGatewayRemedy 9.x
AMQPGatewayN/A
TelnetGatewayN/A
TSRMGatewayN/A
HPOMGatewayN/A
HPSMGatewayN/A
Terminal Emulation TN3270 (MainFrame)ConnectorN/A
Terminal Emulation TN5250 (MainFrame)ConnectorN/A
ItncmConnectorN/A
WsliteconnectConnectorN/A
XMPPGatewayN/A
TibcoBespokeGatewayN/A
Splunk GatewaySDK GatewaySplunk 7.x
SplunkPull GatewaySDK GatewaySplunk 7.x
Jira Service DeskSDK GatewayJira Service Desk 4.x
QRadar GatewaySDK GatewayIBM QRADAR SIEM 7.x
QRadarPull GatewaySDK GatewayIBM QRADAR SIEM 9.x
AssureNow GatewaySDK GatewayFederos AssureOne 4.x
SCOM GatewaySDK GatewayMS SCOM 2012R2
CAServiceDesk GatewaySDK GatewayCA Service Desk 14.x
McAfee GatewaySDK GatewayMcAfee ESM 10.x
MoogSoft GatewaySDK GatewayMoogsoft AI/Ops 7.x
Solarwinds GatewaySDK GatewaySolarwinds NPM 12.x
IBMMQ GatewaySDK GatewayIBM Websphere MQ 8.x
JMS GatewaySDK GatewayWeblogic 14c or Weblogic 12c using wlthint3client.jar from the 14c version (as that from the 12c version is not compatible with OpenJDK 11)
ArcSight GatewaySDK GatewayArcSight ESM 6.8c
Kafka GatewaySDK GatewayKafka 2.2
Zenoss GatewaySDK-2 GatewayZenoss 6.x
Groovy GatewaySDK GatewayN/A
Gateway BuilderSDK-2 GatewayN/A